Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: SSA Refactor IR Review [DO NOT MERGE] #1896

Closed
wants to merge 1 commit into from

Conversation

kevaundray
Copy link
Contributor

Description

Problem*

Resolves

Summary*

Documentation

  • This PR requires documentation updates when merged.

    • I will submit a noir-lang/docs PR.
    • I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

  • I have tested the changes locally.
  • I have formatted the changes with Prettier and/or cargo fmt on default settings.

Comment on lines -58 to 61
/// This map is used to ensure that the ValueId for any given foreign functôn is always
/// This map is used to ensure that the ValueId for any given foreign function is always
/// represented by only 1 ValueId within this function.
/// TODO: can we merge this into intrinsics?
foreign_functions: HashMap<String, ValueId>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must have missed this change when it was merged. I don't think we should ever key any of these maps by a String since it is unclear what it represents (a function name? Any arbitrary one, or one of a set of expected names? Are they expected to be extended later? etc).
I'd be in favor of creating a dedicated enum for foreign_functions (oracles? We use oracle elsewhere so we should be consistent in the naming), or merging them into the intrinsic enum.

@@ -68,6 +69,7 @@ pub(crate) struct DataFlowGraph {
/// Debugging information about which `ValueId`s have had their underlying `Value` substituted
/// for that of another. This information is purely used for printing the SSA, and has no
/// material effect on the SSA itself.
/// TODO: Is this true? How are we doing aliasing?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer true, looks like the comment has been stale for a while now. It should be updated.

@@ -103,6 +105,8 @@ impl DataFlowGraph {
/// block's id.
///
/// The pairs are order by id, which is not guaranteed to be meaningful.
/// TODO: do we need to order by reverse post order? Is this useful? Check brillig
/// TODO: ie do we need to get all successors/predecessors first?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is just for when a pass or test needs to iterate through each block and doesn't particularly care about the order (or whether the blocks are even still reachable). For passes that do care about the order, they can create a PostOrder directly like the Dead Instruction Elimination pass does.

Comment on lines +149 to +151
// TODO: Is simplify still inserting the instruction?
// TODO: or are we assuming that simplify will always return a ValueId that
// TODO: has already been inserted?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simplify may potentially simplify an instruction to an existing, known value (not necessarily a constant). E.g. add x, 0 is simplified to x. So it is expected simplify will always return a valid ValueId if it returns SimplifyResult::SimplifiedTo.

Comment on lines +140 to +141
///
/// TODO: This is doing more than just inserting an instruction and its results
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like the missing piece is that this method attempts to simplify the instruction to another value and only inserts it if it could not do so. We should:

  1. Update the doc comment above to note this.
  2. Potentially rename the function? I'm unsure what a clearer name would be.

Comment on lines -313 to -315
pub(crate) fn import_intrinsic(&mut self, name: &str) -> Option<ValueId> {
Intrinsic::lookup(name).map(|intrinsic| self.import_intrinsic_id(intrinsic))
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we removing this function? It looks like it makes codegen_ident more complex.

let mut max_id = main_id;

// Fetch the max_id from all functions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This map just maps each function id to the function it refers to, keeping track of the max_id is separate.

Comment on lines +25 to 28
// TODO: why is this sorting being done here?
// TODO: does the max_id need to be the main_id initially
// TODO or do generally just need the max_id from all functions?
let mut max_id = main_id;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no sorting being done here, we're just converting the Vec of functions into a btree_map so we can index the map by the function id of each function.

max_id isn't any specific id, it's just used to keep track of what the next free id would be in case we need to add a function to this Ssa struct later and that function needs a fresh ID not shared by existing functions. That is why we initialize next_id: AtomicCounter::starting_after(max_id) later on.

Comment on lines +20 to +21
/// TODO: The above condition is somewhat hidden in the API, should we change it so that
/// TODO the caller needs to pass in the main function?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly, I'm not sure of a clean way to do so however. I think we'd be relying on users to manually extract main from a Vec only to have this function re-insert it afterward. The FunctionBuilder is the only real user of this function I believe so another option is to restrict the visibility a bit more.

@kevaundray
Copy link
Contributor Author

(Note, this will never be merged)

@jfecher
Copy link
Contributor

jfecher commented Aug 15, 2023

Closing this PR as it was not meant to be merged

@jfecher jfecher closed this Aug 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants